Third International Workshop on Analysis of Security APIs

Security APIs are used to define the boundary between trusted and untrusted code. The security properties of existing API are not always clear. In this paper, we give a new generic API for managing symmetric keys on a trusted cryptographic device. We state and prove security properties for the API. In particular, our API offers a high level of security even when the host machine is controlled by an attacker. Our API is generic in the sense that it can implement a wide variety of (symmetric key) protocols. As a proof of concept, we give an algorithm for automatically instantiating the API commands for a given key management protocol. We demonstrate the algorithm on a set of key establishment protocols from the Clark-Jacob suite. Security APIs are used to define the boundary between trusted and untrusted code. They typically arise in systems where certain security-critical fragments of a programe are executed on some tamper resistant device (TRD), such as a smartcard, USB security token or hardware security module (HSM). Though they typically employ cryptography, security APIs differ from regular cryptographic APIs in that they are designed to enforce a policy, i.e. no matter what API commands are received from the (possibly malicious) untrusted code, certain properties will continue to hold, e.g. the secrecy of sensitive cryptographic keys. The ability of these APIs to enforce their policies has been the subject of formal and informal analysis in recent years. Open standards such as PKCS#11 [12] and proprietary solutions such as IBM’s Common Cryptographic Architecture [3] have been shown to have flaws which may lead to breaches of the policy [2, 5, 6, 8, 10]. The situation is complicated by the lack of a clearly specified security policy, leading to disputes over what does and does not constitute an attack [9]. All this leaves the application developer in a confusing position. Since more and more applications are turning to TRD based solutions for enforcing security [1, 11] there is a pressing need for solutions. We propose to tackle this problem from a different direction. We suggest a way to infer functional properties of a security API for a TRD from the security protocols the device is supposed to support. Our first main contribution is to give a generic API for key management protocols. Our API is generic in the sense that it can implement a wide class of symmetric key protocols, while ensuring security of confidential data. The key idea is that confidential data should be stored inside a secure component together with the set of agents that are granted access to it. Then our API will encrypt data only if the agents that are granted access to the encryption key are all also granted access to the encrypted data. In this way, trusted data can be securely shared between TRDs. To illustrate the generality of our API, we show how to instantiate the API commands for a given protocol using a simple algorithm that has been implemented in Prolog. In particular, we show that our API supports a suite of well-known key establishment protocols. Our second main contribution is to state and prove key security properties for the API no matter what protocol has been implemented. We propose a formal model for a threat scenario where TRDs may sometimes be connected to a clean host machine, and sometimes to a corrupted one where the attacker can execute arbitrary code. Additionally, the attacker is assumed to have defeated the tamper resistance on some devices, obtaining the long term keys of some users. We show in particular that our API guarantees the confidentiality of any (non public) data that is meant to be shared between honest agents only (honest agents are those whose TRDs are intact). The property holds even when honest agents